Fixed BoxView in AbsoluteLayout did not return to its default AutoSize for Height and Width after reset #31648
Conversation
|
Hey there @@Dhivya-SF4094! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
dotnet-policy-service
bot
added
community ✨
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a bug where BoxView controls inside AbsoluteLayout on iOS/macOS did not properly return to their default AutoSize state after being reset from explicit bounds. The issue was that the PlatformGraphicsView retained the previous size values, causing the shape to remain visible with its old dimensions.
- Overrides the
GetDesiredSizemethod inShapeViewHandler.iOS.csto return 0 for width/height when those dimensions are NaN (AutoSize) - Adds comprehensive UI tests to validate the fix across platforms
- Updates public API documentation to reflect the new override method
Reviewed Changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
src/Core/src/Handlers/ShapeView/ShapeViewHandler.iOS.cs |
Implements the core fix by overriding GetDesiredSize to handle AutoSize properly |
src/Controls/tests/TestCases.HostApp/Issues/Issue31496.cs |
Creates the UI test page demonstrating the BoxView reset behavior |
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31496.cs |
Implements the automated test to verify the fix |
src/Core/src/PublicAPI/net-ios/PublicAPI.Unshipped.txt |
Documents the new public API method for iOS |
src/Core/src/PublicAPI/net-maccatalyst/PublicAPI.Unshipped.txt |
Documents the new public API method for macOS |
|
/azp run |
jsuarezruiz
added
area-layout
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
| handler.PlatformView?.InvalidateShape(shapeView); | ||
| } | ||
|
|
||
| public override Size GetDesiredSize(double widthConstraint, double heightConstraint) |
There was a problem hiding this comment.
This change is causing some failing tests on iOS and Mac.
Could you take a look?
Example:
Shape_Polygon_Pentagon
There was a problem hiding this comment.
The test case Line_StrokeColor_Thickness passed with my fix.
The following four test cases failed both with and without my fix. So failure is not related to my fix.
- PolyLine_Points_Thickness
- Shape_Polygon_Pentagon
- Polygon_StrokeColor_Thickness
- Polygon_FillColorWithStrokeColor_Shadow
I have ensured with net 10 branch and test fails in net 10 also.
For example:
2 participants
Note
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!
Issue Details:
When a BoxView inside an AbsoluteLayout is defined with AutoSize for width and height, and later its bounds are changed to explicit values and then reset back to AutoSize, the reset fails on iOS.
Root Cause
On iOS/macOS, when a BoxView (or any Shape) inside an AbsoluteLayout is reset back to AutoSize, the control remains visible with its previous explicit bounds.
The issue occurs because the Bounds property in PlatformGraphicsView retains the previous size.
During measure, AbsoluteLayout queries the child’s desired size. Since PlatformGraphicsView.Bounds still holds the old value, the shape continues to visible.
Description of Change
Override GetDesiredSize in ShapeViewHandler.iOS.When VirtualView.Width or VirtualView.Height is NaN, set the corresponding dimension in the returned Size to 0.
This ensures that shapes like BoxView collapse correctly when reset to AutoSize, matching Android behavior.
Validated the behavior in the following platforms
Reference
maui/src/Core/src/Handlers/ShapeView/ShapeViewHandler.Android.cs
Lines 64 to 78 in 3273d2b
Issues Fixed:
Fixes #31496
Screenshots
BeforeFix_31496_iOS.mov
AfterFix_31496_iOS.mov